MVC vs MVVM
MVC has become one of the most popular software design patterns used today. It emphasizes the abstraction of the data layer from GUI interfaces, allowing for faster development. UI designers can focus on HTML/CSS layouts without needing to understand or incorporate data model logic in their work.
While the benefits of using MVC are crystal clear, the definition of what pattern your web app adheres to has become more fuzzy. With the introduction of concepts like MVP and MVVM, design patterns are shifting to an even more strict separation between data and presentation. What classifies as what (MVC vs MVVM vs MVWhatever) is an ongoing debate, however the following is a comprehensive and modern view on this constantly evolving design pattern
MVC Overview
MVC stands for Model, View, Controller. Below is a more detailed description of each:
The Model
The model refers to the data model. This includes anything you are storing and modifying, including DB tables, documents, etc. Models are representations of objects or componets that your app works with. Examples include users, posts, transactions, notifications, messages, etc. Data models are responsible for representing and storing your data, usually in a relational or non relational database. For more on deciding which database is right for you, see MongoDB vs MySQL.
The View
The view is the presentation layer of your application. It displays the data model to the user through a user interface. The view receives updates from the model as a visual representation of the underlying data object. An example would be a user login page. The login form asks you for your username and password. This really represents an underlying user object (or data model) having a 'username' and 'password' attribute.
The Controller
While the view receives updates from the model, it has no way of directly communicating with the data layer. The controller handles all of the 'business logic' of your application. It is the bridge between the view and the model. When a user clicks a button, it fires a function in the controller. This function manipulates the model and also interacts with the view to keep both in sync.
So what?
This makes sense, but why is it important? Why is this a better pattern than others? The abstraction you get from having your data layer isolated from the view provides a strict separation between the front and back end. This allows for faster development. For example, front end developers trying to add CSS to a web form won't have to worry about working around embedded pHp tags or back end logic. The MVC framework delivers a highly organized code base with a clear separation of concerns.
Model View, View Model
This is where things get interesting. Since the advent of single page web apps, the line of front end / back end responsibilities has become increasingly blurred. Developers are now using things like Angular.js and React.js to harness the power of modern day web browsers and deliver both fast and responsive UI's. Using frameworks like Node.js, developers are taking workloads off the server and processing more client side.
This transition has led to the concept of Model view, view model (or MVVM). The key difference between this and traditional MVC is that the controller is replaced with a view model. This view model is bound to the view. Likewise, the view is bound to this view model. This is known as 'two way data binding'. The view model acts as the controller in that it can update the view. Additionally, it receives updates from the view. A more modern example of this is seen with Angular's ng-model directive. Text inputs are directly bound to a data representation of the original model. When a user updates the text field, a $scope variable is also updated on a javascript 'controller'. This controller is really just a view model, which is bound to it's view with the $scope variable.
Confused?
If things are starting to get fuzzy, that's okay. If you got lost after reading about MVC, that's okay too. The problem is developers can't decide how they want to define the controller aspect of their apps. Some argue that the controller is more appropriately labeled a 'view model' through it's adherence to an underlying data object model. Others think of this more as a controller, as the view model is still handling business logic and operations on the data layer. Proponents of Angular even describe it as having the abillity to bring 'client side MVC' to javascript.
Conclusion
Things have gotten pretty fuzzy in determining what separates MVC from MVVM. Angular even classifies its own pattern as 'MV whatever', as valid arguments exist on both sides. Despite the confusion, it is important to understand the concepts behind these arguments. Such design patterns are valuable for writing less code and clearly separating concerns in your code base.
